common-idempotent 幂等使用

幂等概述

幂等性原本是数学上的概念,即使公式 f(x) = f(f(x)) 能够成立的数学性质。用在编程领域,则意为对同一个系统,使用同样的条件,一次请求和重复的多次请求对系统资源的影响是一致的。

幂等性是分布式系统设计中十分重要的概念,具有这一性质的接口在设计时总是秉持这样的一种理念:调用接口发生异常并且重复尝试时,总是会造成系统所无法承受的损失,所以必须阻止这种现象的发生

实现幂等的方式很多,目前基于请求令牌机制适用范围较广。其核心思想是为每一次操作生成一个唯一性的凭证,也就是 token。一个 token 在操作的每一个阶段只有一次执行权,一旦执行成功则保存执行结果。对重复的请求,返回同一个结果或报错。参考《幂等性浅谈》

幂等处理实现

添加依赖

<!-- 幂等插件使用 -->
<dependency>
  <groupId>com.pig4cloud</groupId>
  <artifactId>pigx-common-idempotent</artifactId>
</dependency>

接口增加 @Idempotent 注解

@Idempotent(key = "#key", expireTime = 10, info = "请勿重复查询")
@GetMapping("/test")
public String test(String key) {
    return "success";
}

测试验证

使用 10 个独立线程发起并发请求:

并发测试请求

查看执行结果,10 个请求只会有一个成功:

测试结果

查看后台异常报错,9 个异常报错满足预期:

异常日志

@Idempotent 注解参数说明

参数类型默认值说明
keyString幂等操作的唯一标识,使用 Spring EL 表达式,用 # 引用方法参数。为空则取当前 url + args 作为唯一标识
expireTimeint1有效期,单位由 timeUnit 指定。有效期要大于程序执行时间,否则请求还是可能会进来
timeUnitTimeUnit时间单位,默认为秒
infoString幂等失败提示信息,可自定义
delKeybooleanfalse是否在业务完成后删除 key。true: 删除,false: 不删除
expireTime 设置建议

过期时间需要大于业务执行时间,否则业务请求 1 进来还在执行中,前端未做遮罩或用户跳转页面后再回来做重复请求 2,在业务层面上看,结果依旧是不符合预期的

幂等处理设计原理

流程设计参考

核心流程

  1. 请求开始前,根据 key 查询

    • 查到结果: 报错
    • 未查到结果: 存入 key-value-expireTime,其中 key=ip+url+args
  2. 请求结束后,直接删除 key

    • 不管 key 是否存在,直接删除
    • 是否删除可通过 delKey 配置
  3. expireTime 过期时间,防止一个请求卡死会一直阻塞

    • 超过过期时间自动删除
    • 过期时间要大于业务执行时间,需要大概评估
  4. 此方案直接切的是接口请求层面

  5. 过期时间需要大于业务执行时间,否则业务请求 1 进来还在执行中,前端未做遮罩或用户跳转页面后再回来做重复请求 2,在业务层面上看,结果依旧是不符合预期

  6. 建议 delKey = false。即使业务执行完也不删除 key,强制锁 expireTime 的时间,预防上述情况发生

  7. 实现思路: 同一个请求 IP 和接口,相同参数的请求,在 expireTime 内多次请求,只允许成功一次

  8. 页面做遮罩、数据库层面的唯一索引、先查询再添加等处理方式应该都处理下

  9. 此注解只用于幂等,不用于锁。100 个并发这种压测会出现问题,在这种场景下也没有意义,实际中用户也不会出现 1 秒或 3 秒内手动发送了 50 个或 100 个重复请求,或者弱网下有 100 个重复请求

最佳实践

建议设置 delKey=false,强制锁定 expireTime 时间,避免业务执行完后立即删除 key 导致的重复请求问题

参考资源